home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 443 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  7.2 KB
  1. Date: Mon, 13 Jun 94 15:59 BST-1
  2. From: Ofir Gal <ogal@cix.compulink.co.uk>
  3. Subject: Ofir's digest 13.06
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.368113@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9.  
  10. In message <2tfkqt$2j2@dux.dundee.ac.uk>, bo.leuf@daggskim.ct.se said:
  11. >> CTRL A -                 Select All
  12. >> Shift CTRL A -           Deselect All
  13. >
  14. >ctrl-A is rather easy to hit unintentionally. I would much prefer that the
  15. >order was reversed:
  16. >
  17. > Ctrl-A = Deselect marked (all), i.e. "Abandon" selection
  18. > Shift-Ctrl-A = Select all
  19.  
  20. I must stress again that my initial intention was to join the German
  21. standard with Atari's one. Both use CTRL+A to select all item. I do not
  22. think that changing such a well established key will help.
  23.  
  24. >By similar reasoning, "delete selected objects" is a very strong command since
  25. >in theory "all" can be selected (which can in fact be an entire partition on
  26. >
  27. >I must here agree with the the expressed opinion that Shift-BS is _not_ the
  28. >best choice for a destructive operation, since it is very common to type
  29.  
  30. I am aware of this, but what is the alternative? How about Shift+CTRL+BS
  31. and Shift+CTRL+Del for line operations?
  32.  
  33. >As given however, these are very text(edit)-specific commands, and I'm not
  34.  
  35. Almost all apps handle text in editable fields, all these text operations
  36. apply to these as well as text editors and WP.
  37.  
  38. >entirely happy with them even in this context. I feel that they can be defined
  39. >in a more system-wide general sense and combined functionally with insert (see
  40. >spreadsheets) as follows:
  41. >
  42. >Many programs do make a distinction between an internal copy buffer and
  43. >external clipboard. Delete/insert commands seem best for the former, and
  44.  
  45. Yes, just allow the user to decide whether they want to use the GEM clip
  46. or an internal buffer. This is the case in Everest and Papyrus.
  47.  
  48. >> CTRL D -                 Abandon Window (put in a menu or iconify)
  49. >
  50. >A better English mnemonic here might be "Diminish window".
  51.  
  52. OK.
  53.  
  54. >> CTRL F -                 Find
  55. >> CTRL G -                 Find next
  56. >> Shift CTRL G -           Find previous
  57. >> CTRL R -                 Replace
  58. >> CTRL T -                 Replace Next
  59. >> Shift CTRL T -           Replace previous
  60. >
  61. >Now _why_ make this take more entries than really necessary?
  62.  
  63. An application does not have to implement these. The guidelines only say
  64. that should you wish to implement these then use the above shortcuts.
  65.  
  66. >I am however rather unhappy with Ctrl-G as the selection here, since
  67. > Crtl-G = Goto (line, page, whatever)
  68.  
  69. I have seen Alt+G used for this. CTRL+G is always used for Find Next.
  70. CTRL+J may be used for Goto, the logical (English) mnemonic could be Jump
  71. To. Any objections?
  72.  
  73. > Shift-Ctrl-D = Call up Find&Replace Dialog (with direction toggles)
  74.  
  75. Again, if you read the starting message for this mail list you will find
  76. that the idea is to join the Atari and German standards which are already
  77. well established. Anything else is not exceptable. WE ARE JUST GOING ROUND
  78. IN CIRCLES!!!
  79.  
  80.  
  81. In message <2tfkqt$2j2@dux.dundee.ac.uk>, Annius.Groenink@cwi.nl said:
  82. >
  83. >OK.  Now I've seen at least 5 people (including myself) who would find
  84. >it a prudent decision to swap control A and shift control A.    Isn't
  85. >this a typical point where we should implement a voting system?
  86.  
  87. There will be a vote on this although I strongly object to the idea on the
  88. grounds that it requires each and every application in existance to
  89. change. I do not think we will be taken seriously if we go for that and
  90. our proposal will simply be ignored.
  91.  
  92.  
  93. In message <2tfkqt$2j2@dux.dundee.ac.uk>, Annius.Groenink@cwi.nl said:
  94. >
  95. >Proposal v5:
  96. >
  97. >>CTRL Home -              Move to top of page
  98. >>Shift+CTRL Home -        Move to bottom of page
  99. >>ClrHome -                Move to top of document
  100. >>Shift+ClrHome -          Move to bottom of document
  101. >
  102. >More standard is
  103. >
  104. >   Control Uparrow        Move to top of page
  105. >   Control Dnarrow        Move to btm of page
  106. >   Shift Uparrow          Page up
  107. >   Shift Dnarrow          Page dn
  108.  
  109. OK, I will add this to the proposal. How's that:
  110.  
  111. CTRL left/right arrow -  Move one word left/right
  112. CTRL up/down arrow -     Move to top/bottom of page/frame
  113. Home -                   Move to top of doc
  114. Shift+Home -             Move to bottom of doc
  115. Shift left/right arrow - Move to start/end of line
  116. Shift up/down arrow -    Scroll one screen up/down
  117.  
  118. >> What about standard key for fulling a window?
  119. >>  I use: *
  120. >> And for zooming the window contents?
  121. >>  I use:
  122. >>  + for zoom in, more details
  123. >>  - for zoom out, fewer details
  124. >>  0 for original zoom factor
  125. >
  126. >Yes.  Pretty standard!  I proposed this earlier.  It should at least be implemented
  127. >optionally,  as I've done in Edith.  It applies to practically any GEM application.
  128. >(In Edith +/- means smaller/larger font).
  129.  
  130. I think this should use the CTRL modifier. How about:
  131.  
  132. CTRL * -                 Full window
  133. CTRL + -                 Zoom in/larger font
  134. CTRL - -                 Zoom Out/smaller font
  135. CTRL 0 -                 Zoom 100%
  136.  
  137. >Is anyone actually reading upto this point?
  138.  
  139. Yes...
  140.  
  141.  
  142. In message <199406122018.AA252922313@relay2.geis.com>, dmj@genie.geis.com said:
  143. >
  144. >
  145. > - The German developers had the sense to come up with their own
  146. > - standard long before we did. Give them credit and try to cooperate.
  147. >
  148. >My point is that they developed keyboard shortcuts which make perfect
  149. >sense to them, but are absolutely baffling to those of us who don't
  150. >speak German.  I find it pretty amazing that you want to "marry" two
  151.  
  152.  
  153. No way, if you take a look at the German way of doing things you will find
  154. that there are only a very small number of diffs with the American
  155. (Atari/Compendium). I don't speak German and I don't find German programs
  156. baffling. In fact, the best quality programs tend to come from Germany.
  157.  
  158. >Here's an example, food for thought.  What if you're working with an
  159. >application which is *not* primarily text-oriented?  This leaves
  160. >unshifted letter keys suddenly available for keyboard shortcuts; this
  161.  
  162. I am working on such a program myself (voice mail for F030). I think you
  163. should take a look at programs like Edith, ConNect, Papyrus, and others to
  164. get an idea. If you wish to use the unmodified characters, use them for
  165. program specific function. Are you suggesting that A is better than CTRL+A
  166. or that Q is quicker than CTRL+Q? I'm seriously fed up with programs that
  167. force you to re-learn everything.
  168.  
  169. >Then why are you bothering with us English-speakers?  What I'm trying
  170. >to say is that if you have a single standard which has some things
  171. >difficult for English-speakers to remember, and some things difficult
  172.  
  173. That's not right. It will be easy to remember _anything_ if all apps use
  174. it. Even CTRL+G for quit will be easy if _all_ programs used it.
  175.  
  176. >programmers, it won't be widely accepted--and I will not follow a
  177. >standard which I think doesn't make sense.
  178.  
  179. Fine. I don't see why you are here then. A standard does not need to make
  180. sense. There is no way where every keyboard shortcut is going to make
  181. sense to everyone.
  182.  
  183. >Good point.  Any standard which includes recommendations for what to
  184. >do when you must deviate from it is more foresighted than most.
  185.  
  186. I have not thought about this yet. Can you think of reasons why you would
  187. need to deviate from it? This would help.
  188.  
  189. Bye,
  190.  
  191. Ofir                                    ogal@cix.compulink.co.uk
  192.  
  193.